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(57) Abstract 

A communications system for mobile data transfer, comprising a communications network (25), an application module (45, 46, 47) 
and a separate terminal module (48), where data is transferred between the network (25) and the application module (45, 46, 47) via the 
terminal module (48), which hides network dependent operations such as error control from the application module. By implementing 
the communications stack (12, 13) in the terminal module rather than in the application module, the invention is capable of providing a 
complete communications package, in a portable terminal module (48) or on a single plug-in card, capable of interfacing with a wide 
variety of application modules (45, 46, 47, 92). 
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COMMUNICATIONS SYSTEM FOR MOBILE DATA TRANSFER 



Field of the Invention 

5 This invention relates to a communications system, with particular but not 
exclusive application in mobile data transfer over networks based on the 
Internet Protocol. 

Background 

10 Mobile data communications systems are well known. For example, to 
connect to the mesh of networks, or internetwork, known as the Internet, 
most mobile data users currently use a combination of a GSM mobile 
telephone together with a data card and suitable host platform, typically a 
notebook computer running one or more application programs such as e-mail 

15 or remote file transfer across the network. Generally, mobile systems require 
that the mobile host is reachable at the same address as it moves across 
different networks, with continuous connectivity and seamless roaming even 
while a network application is running. 

20 The architecture of a generalised communications system may be conveniently 
described by reference to the well-known 7-layer International Standards 
Organisation (ISO) reference model, shown in Figure 1. 

The model portrays a communications subsystem comprising two host 
25 computers A and B, each represented by seven protocol layers 1 to 7, 

connected through a data network 8 via a gateway or router 9. The arrows 
between the layers indicate the logical connections between them. Each layer 
in the model performs a well defined function and operates according to a 
defined protocol, which allows it to exchange messages with the 
30 corresponding layer in a remote system. In practice, this exchange is possible 
through data encapsulation: at the transmitting host, data generated by the 
user application process (AP) 10 is passed down the layer stack as a series of 
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data units, with each layer adding control information to the units until they 
are in a form capable of being sent across the network. At the receiving host, 
each received data unit passes up the layer stack towards the user AP 10, each 
receiver layer stripping out the control information produced by the 
5 corresponding transmitter layer. 




99/39488 



10 



Layers 1 to 3 are said to implement network dependent functions, the detailed 
operation of which varies between different network types. Layer 1, the 
physical layer, provides the physical, for example, electrical means for 
transmitting a serial bit stream across the network 8. Layers 5 to 7 are said to 
implement application oriented or network independent functions, with layer 
7, the application layer, providing the user interface. Layer 4, the transport 
layer, acts as an interface between the network dependent and the application 
oriented layers, providing the session layer 5 above it with a message transport 
15 facility which is independent of the underlying network. The transport layer 
is responsible for end-to-end message transfer between Host A and Host B, 
including functions such as connection management and error control. 
Reference is directed to "Data Communications, Computer Networks and 
Open Systems", Fred Halsall, Addison-Wesley, 4th Edition, Chapter 1.3, for a 
20 detailed description of the ISO reference model. 

Within the Internet, data transfer is based on a set of protocols generically 
referred to as TCP/IP, which provides a layered protocol architecture 
commonly referred to as a protocol or communications stack. As well as 
25 basic network protocols, the TCP/IP protocol suite includes a number of 
well-known application protocols, including the File Transfer Protocol (FTP) 
and the Remote Terminal Protocol (TELNET). A simplified diagram of the 
logical structure of these layered protocols is shown in Figure 2. 



30 



The TCP/IP suite is generally described on the basis of a 4-layer model, rather 
than the 7-layer ISO model of Figure 1, although there is general 
correspondence between the two models. The application protocol layer 11 
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encompasses layers 5 to 7 in the 7-layer model and provide functions such as 
remote file transfer (FTP), remote terminal login (TELNET) and e-mail 
(SMTP). The TCP/UDP (Transmission Control Protocol/User Datagram 
Protocol) layer 12 corresponds to layer 4 in the 7-layer model. TCP and 
UDP are transport protocols concerned with the management of end-to-end 
message transfer between two hosts. The IP (Internet Protocol) layer 13 
corresponds generally to layer 3 and the Network Interface layer 14 
corresponds to layers 1 and 2 in the 7-layer model, and provides the means for 
converting between data units at the IP layer and the data format required for 
transmission over the physical network 8, for example, Ethernet frames for an 
Ethernet based network. 

The Internet Protocol (IP) provides a number of core functions and associated 
procedures necessary when working across dissimilar networks, including 
fragmentation and re-assembly of user messages, network routing and 
addressing. Data is transferred in the form of data units known as IP 
datagrams between points in the Internet specified by IP addresses. The 
detailed specification of IP is available in a "Request for Comments" 
document, RFC 791, maintained by the Internet Engineering Task Force 
(IETF), which is widely available on the Internet at, for example, 
"ftp://ds.internic.net/rfc/rfc791.txt". As well as being central to Internet 
technology, IP is widely used as the basic protocol for data transfer in 
internetworks outside of the Internet. 

Data transfer within the Internet may take place on a connectionless or 
connection-oriented basis, depending on the protocol used. User Datagram 
Protocol (UDP) provides a connectionless IP datagram delivery service which 
does not maintain an end-to-end connection between transmitting and 
receiving hosts and therefore does not guarantee delivery. It merely treats 
each datagram as a self-contained entity to be transferred on a best-try 
approach. It is up to the application using the UDP service to perform error 
checking: if it does not do so, it has no way of knowing if a datagram has 
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arrived at the receiver or if it has been lost in transit. This form of transfer is 
suitable for some types of data, for example image or voice data, where speed 
may be more important than occasional errors, which are unlikely to 
substantially affect the received image or speech quality. 

5 

However, for most applications, a reliable connection-oriented service is 
required, which guarantees IP datagram delivery. The Transmission Control 
Protocol (TCP) is a connection-oriented protocol which maintains an end-to- 
end connection between pairs of communicating processes running on host 
computers, and provides a reliable and secure logical connection for data 
transfer between the processes. 



10 



TCP assumes that it can obtain a simple but potentially unreliable data service 
from the IP layer below it. To turn this into a reliable service, it therefore 

15 has to provide a range of functions including (a) basic data transfer, (b) 

reliability and error correction, allowing recovery from damaged or missing 
data or data delivered out of sequence, (c) flow control, which provides the 
receiving host with the means to govern the amount of data sent by the 
transmitting host, (d) multiplexing, which allows many processes within a 

20 single host to use its TCP facilities simultaneously, (e) maintenance of 

connection information for each connection between two processes, and (f) 
precedence and security. The TCP specification setting out the detailed 
requirements for implementation in each of these areas is available as RFC 
793. 



25 



30 



In known systems, the TCP/IP protocol stack is implemented in software, 
and is normally resident in, and an integral part of, the operating system of an 
application module, for example, a notebook computer. User access to the 
TCP through the operating system is comparable to similar processes such as 
user access to the computer's file system. A variety of TCP/IP 
implementations are commercially available for different platforms such as 
DOS and UNIX, for example, Microsoft TCP/IP software is provided as an 
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integral part of the Microsoft Windows 95 and Windows NT operating 
systems. 

Referring to Figure 3, the way in which TCP operates to transfer data 
5 between two host computers may be illustrated by reference to the well- 
known client-server model. For example, one of the fundamental 
requirements in distributed systems is for access to information stored on 
remote file servers. FTP provides such access. Client A may be an 
application module such as a notebook computer and the remote computer B 
10 from which it requests information is known as the server. Both client and 
server operating systems contain TCP/IP modules. 



The user accesses the client FTP process 16 by issuing commands through the 
client terminal 17. Alternatively, a user program/ application process (AP) 17 

15 may access FTP. In either case, the user commands are passed to the client 
operating system 18 which calls the client FTP 16. The client FTP calls the 
TCP module 19 via the operating system 18. The client FTP 16 uses the TCP 
data transfer service between client and server TCP modules 19, 20 to send 
the commands to the server FTP 21. The server FTP then accesses its local 

20 file system 22 through its operating system 23, according to the commands 
specified by the user, and transmits the required data back to the client FTP 
16 for presentation to the user. The way in which TCP establishes 
connections to the remote server is described below. 



25 To identify the separate data streams that a TCP implementation within a 
host can handle, the TCP 19 provides a port identifier 24 for each separate 
process. Port identifiers are selected independently by each TCP and so may 
not be unique. To provide for unique addresses, the port identifier is 
combined with the IP address of the host to create a socket which will be 

30 unique throughout all networks connected together. A connection is fully 

specified by a pair of sockets at each end, one at the client TCP 19 and one at 
the server TCP 20. Each host socket may participate in many separate 
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connections. 

The sockets model was originally developed by Berkeley Software 
Distribution (BSD) at the University of California at Berkeley and is the 
5 standard on which all TCP/IP software is based, with the aim of providing a 
common interface for network use on any particular operating system. In the 
case of Microsoft Windows based platforms, an applications programming 
interface (API) known as Microsoft Winsock (Windows sockets) implements a 
Windows based version of the BSD sockets model. Winsock software is 
10 installed alongside TCP/IP in Windows based systems to permit the 
interoperability of applications and TCP/IP implementations written to 
comply with the Winsock specification. The Microsoft Winsock specification 
is available on the Internet at a variety of sites, including for example: 
ftp:/ / ftp.microsoft.com/bussys/Winsock/specl 1 .txt. 

15 

The port identifier forming part of the socket is pre-defined for a number of 
well-known processes such as FTP and TELNET: for example, any server 
implementing the FTP process is given the port number 21, so that the FTP 
process running on any server may be accessed simply by connecting to port 
number 21 of that server. Reference is directed to the TCP specification at 
RFC 793 cited above for a description of the way in which sockets are 
established, maintained and closed. 

As a result of the extensive functionality provided by TCP, one problem 
25 associated with its use is the large overhead resulting from the implementation 
of the full TCP/IP protocol stack, both in terms of the memory required and 
because the additional processing performed by TCP, as required for most 
network applications, substantially increases the processing load on the client 
processor. 



20 



30 



Summary of the Invention 

To address the above problems, the present invention provides a 
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communications system for mobile data transfer, comprising a 
communications network, an application module capable of processing 
network data, and a separate terminal module configured to provide a 
network independent data transport service to the application module. 

5 

Network data may be data which originates at the network and is destined for 
the application module or vice versa. 



The system according to the invention appreciates that the complexity of the 
10 protocol stack may be transferred from each of a plurality of application 
modules to a separate terminal module. The communications system may 
then comprise a single complex terminal module and one or more relatively 
simple application modules. This enables the construction of a variety of 
cheap application modules with limited functionality, and therefore a reduced 
15 level of complexity and cost compared with a conventional system, since there 
is no need to provide the memory space and processing power for 
sophisticated data transfer management, which is dealt with by the terminal 
module. 



20 The removal of the protocol stack into a separate device also enables the use 
of a wider variety of application modules with the system, where application 
modules were previously incapable of implementing the complexity of the 
TCP/IP protocol stack. 

25 In a system according to the invention, the application module may be 
configured so that data transfer between the network and the application 
module can only take place via the terminal module. 

Data transfer between the network and the terminal module does not involve 
30 any processing within the application module, so that high overhead 

operations such as error checking do not place a load on the application 
module operating system or processor. These operations may be carried out 
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by a processing unit within the terminal module. When data transfer to the 
application module is required, that transfer may be carried out between the 
terminal module and the application module across hardware links, with very 
low bit error rates. 

5 

The hardware links may be in the form of physical wiring, for example, 
utilising the existing serial ports on a standard computer, or may be infra-red 
links. Various other forms of link including optical fibre connections are also 
envisaged. 



10 



15 



As well as error control, the terminal module may be used to carry out all 
connection management, data fragmentation and flow control tasks, so hiding 
the detailed operation of the underlying network from the application 
modules. 



The separation of the protocol stack from the application modules means that 
no protocol is defined for transfer of data between the terminal module and 
each application module. A protocol must therefore be specified to ensure 
that application processes running in all types of application modules should 
20 be able to access the stack in a uniform manner. The present invention 
accordingly further provides that the terminal module and the application 
module each include means configured to provide a logical connection 
between them. 



The load on the application module processor can be lightened further by 
incorporating into the terminal module at least some of the functionality of 
the session and presentation layers in the general 7-layer model. For example, 
network data can be converted into standard ASCII format by the terminal 
module prior to being communicated to the application modules. The 
disadvantage of this approach is that greater functionality at the terminal 
module can lead to a reduction in flexibility at the application modules. 
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According to a second aspect of the invention, there is provided a terminal 
module for a mobile communications network, comprising a first connecting 
means for connecting the terminal module to the network and a second 
connecting means for connecting the terminal module to a separate application 
5 module, wherein the terminal module is configured to provide a network 
independent data transport service to each of a plurality of separate 
application modules. 



Preferably, the terminal module is in a form and of a size which may be 
10 conveniently carried by the user at all times, for example mounted on the 
user's belt. The device may be incorporated into a PCMCIA-style card, 
which is easily carried and which may be conveniently connected to an 
application module by plugging the card into a corresponding slot in the 
module. As a result, this invention can provide a complete communications 
15 package on a single plug-in card. 

The invention further provides a method of transferring data to an application 
module in a communications network, comprising receiving data destined for 
the application module at a terminal module separate from the application 
20 module and processing the received data so as to provide a network 
independent data transport service for the application module. 

Brief Description of the Drawings 

Embodiments of the invention will now be described by way of example, 
25 with reference to the accompanying drawings, in which: 

Figure 1 shows the 7-layer ISO reference model for a general communications 
subsystem; 

Figure 2 is a schematic diagram showing the protocol architecture of the 
30 protocols within the TCP/IP protocol suite; 

Figure 3 is a schematic diagram showing the client/server model applied to an 
FTP process within the Internet; 
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Figure 4 is a schematic diagram showing a conventional data communications 
system; 

Figure 5 is a flow diagram illustrating the operation of the system of Figure 4; 
Figure 6 is a schematic diagram showing a system according to the present 
5 invention; 

Figure 7 is a schematic representation of the terminal module and an 
application module; 

Figure 8 is a flow diagram illustrating the operation of the system of Figure 6; 
and 

10 Figure 9 illustrates a practical application of a system according to the present 
invention. 



Detailed Description 

Referring to Figure 4, a conventional data communications system comprises 
15 an IP based network 25 connected to the Internet (not shown) via a gateway 
26. A plurality of application modules including notebook computers 27, 28 
and an integrated palmtop computer/ mobile telephone 29, such as the Nokia 
9000 Communicator, may be connected to the network 25. For example, a 
notebook computer 27 is connected to the network 25 by means of a data 
20 card 30 and GSM mobile telephone 31 through mobile IP based RF cells 32. 
The connection is typically established through an Internet Service Provider 
(ISP) which provides access to the Internet. Other application modules such 
as the notebook computer 28 may connect to the Internet through a hard- 
wired connection 33, for example through the computer's standard serial port, 
25 or by an infra-red link 34 using an infra-red port on the notebook to connect 
to an infra-red port 35 on the network 25. Each application module 27, 28, 
29 has a TCP/IP communications stack installed as part of its local operating 
system and allows communication to be established with an Internet based 
host (not shown) through one or more reliable TCP connections. 

30 

The operation of the conventional system may be understood by reference to 
an application process, for example a user using a notebook computer with 
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FTP and TCP/IP installed, accessing a remote file system, as shown 
schematically in Figure 5. 



For clarity and simplicity, it is assumed that the client FTP knows the IP 
5 address of the destination server, an operation which would normally be 
carried out separately by reference to a host computer known as a domain 
name server. Referring to Figure 5, the user requests access to a remote file 
on the file server 40 by keying in commands at the application module 
terminal 41, specifying the server location and the file name. The operating 

10 system (not shown) issues an "f_open" request to the client FTP 42 (step si). 
In turn, the client FTP 42 issues an ACTIVE_OPEN request to the client 
TCP module 43 (s2) specifying the port identifier (21 is the well-known port 
for FTP) and the IP address of the server 40. The client TCP 43 responds 
with an OPEN ID message (s3) informing the client FTP 42 of the local 

15 connection name which TCP has assigned to this connection. The client 

TCP 43 then seeks to establish the connection to the server 40 (s4 - s9). The 
sequence of protocol commands through which the TCP modules 43, 44 co- 
operate to establish the connection and the subsequent data transfer is well- 
known and is fully documented in the TCP specification (RFC 793). 

20 Reference is further directed to "Data Communications, Computer Networks 
and Open Systems", Fred Halsall, Addison-Wesley, 4th Edition, Chapters 11, 
13 and 14 for an overview of the process. 

Referring to Figure 6, a system according to the invention comprises a 
25 network 25 connected to the Internet (not shown) via a gateway 26, a number 
of application modules 45, 46, 47, and a separate terminal module 48. The 
application modules 45, 46, 47 are not directly connectable to the network 25 
but are connectable to the terminal module 48. The terminal module 48 is in 
turn connectable to the network 25. In contrast to the application modules 
30 27, 28, 29 in the conventional system, application module 45, 46, 47 in a 
system according to the invention do not contain a communications stack, 
which is implemented only in the separate terminal module 48. 
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Each application module 45, 46, 47 may be connected to the terminal module 
48 in a number of different ways. For example, the terminal module 48 and 
the application module 46 each include an infra-red port (not shown), 
comprising an infra-red transmitter and receiver, and may therefore transmit 
5 and receive data conforming to the IrDA (Infra-red Data Association) 

standard. IrDA compliant devices within application modules are becoming 
increasingly common; for example, the Psion 3c palmtop computer includes 
an infra-red port, as do the Gateway Solo range of notebook computers, from 
Gateway 2000 Europe, Dublin, Ireland. The provision of an infra-red port 
10 allows a number of application modules to communicate with the terminal 
module 48 as long as each is within range. 

Alternatively, or in addition, the terminal module 48 is provided with a 
PCMCIA-style card connector 49 which plugs into a corresponding slot in an 

15 application module 45, such as a notebook computer. Although it is possible 
to use a true PCMCIA card with existing application modules such as 
notebook computers, it is envisaged that a much simpler hardware based 
protocol be used over the terminal module to application module connection, 
as described in detail below. To ensure compatibility with existing notebook 

20 computers, the physical connection between terminal module 48 and 
application module 45 can be provided by using a card which meets the 
physical PCMCIA specification but not the electrical specification, referred to 
herein as a "PCMCIA-style" card. In an alternative embodiment, the terminal 
module 48 is entirely contained on a single PCMCIA-style plug-in card which 

25 may itself be plugged into the corresponding slot in an application module. 

The terminal module 48 may be connected to the network 25 by a number of 
different means, including a direct wire link 50, an infra-red (I-R) link 51 
and/or radio frequency (RF) links 52 via the mobile-IP based RF cells 32 of 
30 the network 25. Different options may be included in the device 48 according 
to the user's requirements. In the case of the infra-red link 51 and radio 
frequency link 52, the terminal module 48 and the network 25 each comprise 
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an appropriate transmitter and receiver (not shown). 

Referring to Figure 7, the terminal module 48 comprises a network interface 
60, a processing unit 61 and an operating system (OS) 62 which includes a 
number of modules. The modules are a TCP/IP module 63, a Sockets 
Interface module 64 and a Hardware Socket module 65. Finally, the device 48 
includes an input/output interface 66. 

The terminal module 48 is, for example, a conventional notebook computer, 
such as a Gateway Solo 9100. The network interface 60 is provided by a 
conventional GSM mobile telephone connected to the notebook 48 through a 
suitable data card, for example a Nokia PC card for Nokia 21 series GSM 
telephones. The notebook's integral infra-red port may also be used to access 
the network and a direct wire link is provided with a suitable network card, 
for example a 3Com Ethernet Combo PC card and Ethernet cable, assuming 
an Ethernet 10BASE-T network 25. The processing unit 61 is provided by 
the processor and associated circuitry of the notebook 48. The notebook 48 is 
pre-loaded with operating system 62 and suitable TCP/IP software to provide 
the TCP/IP module 63. For example, network access is provided on a 
notebook running Microsoft Windows 95 by configuring the pre-loaded 
Microsoft TCP/IP software and loading Microsoft Winsock software, which 
may be downloaded from the Internet at, for example, ftp://ftp.microsoft.com 
/bussys/WinSock/winsock2. The notebook 48 uses its infra-red port 66 for 
communications with the application modules 45, 46, 47. The Sockets 
Interface 64 and Hardware Socket 65 are software modules designed to reside 
in the operating system 62, the functionality of which is described in detail 
below. 

Each application module 45, 46, 47 comprises a processor 67 capable of 
running an application process 68, an input/output port 69 for connection to 
the terminal module 48 and an operating system (OS) 70 including a Dummy 
Sockets Interface module 71 and a Hardware Socket module 72. The 
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input/output port 69 includes the facility for a direct wired connection, an 
infra-red transmitter/receiver and/or plug-in card connector. A generalised 
application module 45 is defined by reference to a Gateway Solo 9100 
notebook computer, as for the terminal module 48. This is provided with a 
5 processing unit to run an application process, for example an FTP program 
and an infra-red transceiver, as described above. The Dummy Sockets 
Interface 71 and Hardware Socket 72 are software modules designed to reside 
in the operating system 70, as described in detail below. 

10 The combination of the terminal module 48 and a single application module 
45 may be considered to define a communications subsystem. Referring to 
Figure 2, the terminal module 48 implements layers 12, 13 and 14, 
corresponding to layers 1 to 4 in the 7-layer model. The application module 
implements layer 11, corresponding to layers 5 to 7 in the 7-layer model. The 

15 connection between the terminal module 48 and the application module 45 
completes the communication subsystem. 

To allow comparison with the conventional system, the operation of the 
system according to the invention will be described in terms of a request by a 
20 client notebook computer for transfer of a data file from a remote server. 

Referring to Figure 8, a user at the notebook terminal 80 enters a request for 
a remote file from the file server 81, specifying the name of the server and the 
file name. As with the conventional system described at Figure 5, it is 

25 assumed that the client FTP 82 has already obtained the IP address of the 
server. The local operating system issues an "f_open" request to the client 
FTP 82 (sll), which issues an ACTTVEJDPEN command (sl2) which is 
passed by the operating system (not shown) to the address at which TCP/IP 
would normally be resident. Since TCP/IP is not present, the Dummy 

30 Sockets Interface module 71 is located at the TCP address and is designed to 
present the same front-end to the operating system and therefore to accept the 
operating system call as if it were the TCP/IP module. This ensures that 
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existing applications such as FTP and Telnet which generate standard calls to 
TCP do not require modification to be used with the system according to the 
invention. The function of the Dummy Sockets Interface 71 is to convert the 
operating system call into a form which can be used by the Hardware Socket 
5 72 to communicate with the Hardware Socket 65 in the terminal module 48. 
The Dummy Sockets Interface 71 therefore implements a look-up table which 
contains a unique token corresponding to each operating system call. The 
token for the ACTTVEOPEN command may simply be a number, for 
example decimal "10". 

10 

The respective Hardware Sockets 72, 65 communicate by passing such tokens 
(sl3), which may take a variety of physical forms depending on the nature of 
the input/output interface 66, 69. For example, the token may be represented 
as a binary sequence on bus lines or a voltage level on an analog line or a 

15 burst of light on a particular frequency over an optical link. In the case of an 
infra-red link, transmission of a token can be implemented by direct 
modulation of an infra-red emitter, using on-off keying (OOK), with binary 1 
turning the emitter on and binary 0 turning it off. Reference is directed to 
"Data Communications, Computer Networks and Open Systems", Fred 

20 Halsall, Addison-Wesley, 4th Edition, Chapter 6, pages 332 - 334 for a detailed 
description of infra-red modulation techniques. 



Assuming that the devices make use of the infra-red capability of the 
respective notebook computers, the terminal module Hardware Socket 72 

25 transmits an infra-red pulse sequence corresponding to the token "10", which 
in turn corresponds to the ACTIVE OPEN request, for example, by direct 
modulation of the infra-red emitter in the input/output interface 69, to the 
infra-red receiver in the input/output interface 66 of the terminal module 48. 
The Hardware Socket 65 demodulates the received signal and passes the token 

30 to the Sockets Interface 64 which regenerates the ACTIVEOPEN request 
from its look-up table and passes it to the TCP/IP module 63 (sl4). 
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Once the ACTIVE_OPEN command is received by TCP/IP, it issues a 
connection identifier and sends an OPENJD message back to the application 
module FTP 82 over the infra-red connection (sl5 - sl7) by the token coding- 
decoding process described above, before seeking to initiate the connection to 
5 the server (sl8 - s22). The way in which the TCP seeks to set up a 

connection-oriented data transfer path between the terminal module 48 and 
the remote server 81 connected to the Internet (si 8 - s22) is entirely 
conventional and is described above in relation to Figure 5. 

10 As well as the tokenised form of the commands, parameters may be passed 
using similar encoding principles. 

Data transfer from the terminal module 48 to the application module 45 may 
take place while data is being transferred from the server, as soon as blocks of 
15 error-free data are available. Alternatively, the terminal module 48 may be 
provided with a substantial memory capability, for example, the integral hard 
disk on a notebook computer, in which data from the server is stored for later 
transmission to the application module 45. 

20 The Hardware Socket software may operate with any sort of device which 
allows data to be transmitted serially or in parallel. In a typical notebook 
computer, the Hardware Socket may control a serial or parallel port as well as 
the I-R port. In each case, the Hardware Socket is implemented by software 
code which converts tokens from the Sockets Interface into a form which can 

25 be transmitted over an appropriate hardware device, and vice-versa. 

The terminal module 48 may of course be a proprietary unit rather an existing 
device, built to meet the requirements specified above without the additional 
features such as a keyboard provided as standard in existing devices such as 
30 notebook or palmtop computers. The Sockets Interface and Hardware Socket 
are implemented in software to interface with a commercially available 
TCP/IP stack. 
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The application modules 45, 46, 47 may be similarly implemented with the 
minimal functionality required, so as to reduce cost. Conventional processing 
circuitry is provided together with operating software to run required 
applications and to interface with the Hardsock and Dummy Sockets Interface 
5 modules in memory. The operating software may be a system such as ELKS, 
a freely available cut-down version of UNIX which is designed to run on low 
power processors. A conventional data interface is required to communicate 
with the terminal module 48. This is implemented, for example, using a 
USART chip such as the Intel 8251 A available from Maplin Electronics, UK. 
10 This is microprocessor programmable to provide a serial data input/output 
conforming to the standard RS-232 protocol, which can be connected to the 
terminal module directly or via an infra-red transceiver. 



As with software sockets, a number of logical paths may be opened between 
15 the Hardware Socket modules to different application modules, for example, 
where a number of application modules 45, 46, 47 are simultaneously within 
infra-red range of the terminal module 48. Transmission/reception to and 
from each device may be on a simple round-robin basis. In a software sockets 
environment, when a socket is opened, a unique number is returned to be 
20 stored by the application for future use of the socket, and for the operating 
system to maintain the context for that socket. This identifier is known 
generically as a socket handle. Such a handle can be used in relation to the 
present invention, with the unique handle being sent as a tokenised parameter. 

25 In a particular embodiment of the invention, the terminal module 48 
comprises a plug-in PCMCIA-style card which includes an infra-red 
transmitter/ receiver, a processor and memory, with operating software such as 
the ELKS system together with the Sockets Interface and Hardware Socket 
being implemented in software in the body of the card, so that connection is 

30 by plugging the card into a corresponding PCMCIA slot in the application 
module 47, with appropriate driver software implemented in the Hardware 
Socket 72 of the application module. 
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Referring to Figure 9, the system may be used within an office to keep users 
appraised of information relevant to their needs. For example, the device in 
the form of a roaming unit with integral card 48 is carried with the user at all 
times in moving around a large office. Infra-red transmitters 90 are mounted 
5 in the ceiling 91 from which data is transmitted to the card 48 when the user 
is within range. That data is stored within the terminal module memory until 
the user requires to access it, when he or she may approach a standard 
application module terminal 92 and retrieve the information by plugging the 
card into a corresponding slot on the terminal 92. 

10 

When the user moves outside the office environment, the device may switch 
to a radio frequency mode in which it continues to receive data targeted at it. 
Such data may then be read by plugging the card into a slot provided on, for 
example, a palmtop computer, from which messages may also be sent back to 
15 the network. 

Although the invention has been illustrated by reference to a TCP/IP 
protocol stack based on the Internet, the principles are applicable to other 
networks and internetworks, whether using the TCP/IP stack or other 
20 communications protocols, such as the OSI Internet Protocol. 
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Claims 



10 



1- A communications system for mobile data transfer, comprising: 
a communications network (25); 

an application module (45, 46, 47) capable of processing network data; and 
a separate terminal module (48) configured to provide a network independent 
data transport service to the application module. 

2. A system according to claim 1, wherein, as between the application 
module and the terminal module, only the terminal module includes a 
protocol stack (12, 13). 



3. A system according to claim 1 or 2, wherein the data format for data 
transfer between the network and the terminal module is different to that 

15 between the terminal module and the application module. 

4. A system according to any preceding claim, wherein data transfer 
between the network and the terminal module is independent of data transfer 
between the terminal module and the application module. 

20 

5. A system according to any preceding claim, wherein the application 
module is configured such that data transfer between the network and the 
application module can only take place via the terminal module. 

25 6. A system according to any preceding claim, including: 

first means (50, 51, 52) for connecting the terminal module to the network; 
and 

second means for connecting the terminal module to the application module. 



30 



7. A system according to claim 6, wherein the first connecting means 
includes an infra-red link (51). 
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8. A system according to claim 6 or 7, wherein the second connecting 
means includes an infra-red link. 



9. A system according to any one of claims 6 to 8, wherein the second 
5 connecting means includes a card (49) configured to be connected in a 

corresponding slot in the application module. 

10. A system according to any one of claims 1 to 5, wherein the terminal 
module comprises a card (48) configured to be plugged in to a corresponding 

10 slot in the application module. 

11. A system according to any one of the preceding claims, wherein the 
terminal module and the application module each include means configured to 
establish a logical connection between them (64, 65, 66, 69, 71, 72). 

15 

12. A system according to claim 11, wherein the connecting means 
comprises a hardware socket (65, 72). 

13. A terminal module (48) for a mobile communications network (25), 
20 comprising: 

a first connecting means (50, 51, 52) for connecting the terminal module to 
the network; and 

a second connecting means for connecting the terminal module to a separate 
application module (45, 46, 47); 
25 wherein the terminal module is configured to provide a network independent 
data transport service to each of a plurality of separate application modules. 

14. A terminal module according to claim 13, wherein the first connecting 
means includes an infra-red transmitter and receiver. 



30 



15. A terminal module according to claim 13 or 14, wherein the second 
connecting means includes an infra-red transmitter and receiver. 
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A terminal module according to claim 13, comprising a PCMCIA-style 



17. A method of transferring data to an application module (45, 46, 47) in 
5 a communications network, comprising: 

receiving data destined for the application module at a terminal module (48) 
separate from the application module; and 

processing the received data so as to provide a network independent data 
transport service for the application module. 

10 

18. A communications system substantially as hereinbefore described with 
reference to the accompanying drawings. 



19. A terminal module substantially as hereinbefore described with 
15 reference to the accompanying drawings. 

20. A method of transferring data to an application module in a 
communications network substantially as hereinbefore described with 
reference to the accompanying drawings. 

20 
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